Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Distributed Systems

In a distributed server system, two or more systems work in tandem to appear as one server. One large database may in fact be distributed across several servers. Each server in the system is maintained independently; together, they form a consistent view of the data.

Distributed systems frequently take advantage of two-phase commits to guarantee that transactions are atomic. Without the two-phase commit, it would be very difficult to ensure data consistency and integrity.

Depending on the configuration of your system, you may have some local transactions, some remote transactions, and some distributed transactions. These types of transactions are defined as follows:

  Local transactions. Those transactions that occur only on the local node.
  Remote transactions. Those transactions that occur only on a remote node.
  Distributed transactions. Those transactions that affect data on both the local and remote nodes.

All three of these transaction types are available in a distributed database. It is desirable to make this fact transparent to the end user. The end user does not care whether the transaction was remote, performed locally, or of a distributed nature.

A distributed system sometimes takes advantage of data replication (refer to the preceding section). If you combine a distributed system and replicated system, not only is the system load distributed, it is protected by the replication as well.

System Characteristics

The characteristics of a distributed system are based entirely on the characteristics of the type of transactions being run on it. The distributed system has no unique characteristics except for slightly higher requirements for a high-performance, reliable network interface.

Because much of the work done relies on other servers (for example, two-phase commits), it is important to have a high-speed link between the servers. This requirement is the only major differentiating factor for the distributed system.

Design and Tuning Hints

A distributed system is configured and tuned entirely based on the application running on that server. You should make no special tuning or design changes for the distributed system, except in the networking area.

Because the distributed transaction may involve either the client machine or the server in executing a two-phase commit, you should optimize the performance of the network both from a client-to-server and server-to-server perspective. If necessary, you may want to add a dedicated link between servers and provide a high-speed network between clients and servers.

Whether or not the network must be enhanced depends on your configuration and load. In any case, enhancing the network can be easy: simply add faster components or segment the network.

Review of the Distributed System

There is very little that is necessary to enhance the performance of a distributed system. Base your tuning and configuration efforts on the type of transactions that will be run on this server.

Distributed systems are common and can be useful for providing load-sharing among servers and access to a wealth of nonlocal data. The main task of the distributed system is to appear to the user as a single large database. The performance of the overall system is enhanced by allowing multiple systems to service requests.

By splitting the work between multiple servers, each system can focus on a subset of the data. Depending on the configuration of your system, you may have some local transactions, some remote transactions, and some distributed transactions. The fact that the database is distributed is transparent to the user.

TextServer 3.0 Systems

The Oracle TextServer 3.0 system is an Oracle add-on designed to assist with the storage, retrieval, and processing of textual data. TextServer 3.0 works with text data stored in an Oracle database and text external to the database. This chapter describes only the text data stored in the Oracle database itself.

Using TextServer 3.0, you can not only store and retrieve text but perform additional useful functions such as indexing and textual search functions. Searches of the textual data can be done with a word search using a pattern-matching algorithm; alternatively, you can use a theme search if you need a thesaurus to match a meaning.

TextServer can be used by itself or with Oracle ConText, a text-processing system that allows for searches based on context, phrases, or themes. Because it is not feasible to search the document every time you look for a certain theme, the use of indexes is imperative.

System Characteristics

In a TextServer system, textual data is stored in the database using the LONG data type. The characteristics of this type of system are similar to those of the BLOB system. The data in the documents is stored in an unstructured state and has the following characteristics:

  Significant size. Each record is usually significant in size. Although the size depends on your particular documents, having rows of several hundred kilobytes or more than a megabyte is not uncommon.
  Binary data. The documents may contain ASCII data or may be in a binary format.
  Compression. Because the data may be binary and large, it may or may not be stored in a compressed state. This depends on the database and the application.

As you can see, many of the characteristics of a TextServer system are similar to those of the BLOB system. As with the BLOB system, the TextServer system has some unique data access patterns.

This type of system has one or more tables with records of a megabyte or more. When this data is accessed, there is a continuous data access to a single record. In the other types of database applications you have seen, it is unlikely that a single record is larger than a data block; with TextServer data, you are almost guaranteed that a single row spans multiple data blocks.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.